I do not agree with this approach. Unless I am misreading the code, it is silently resizing the image by a few pixels which will cause blurry heavily antialiasing artifacts on any text, lines or pixel art. The user will be unaware of why their art is getting corrupted when basisu is used.

There is no requirement I can see that textures are rounded to a multiple of 4:
https://registry.khronos.org/OpenGL-Refpages/es3.0/html/glCompressedTexImage2D.xhtml
Therefore, the correct approach should be to smear average pixels over the last 4x4 blocks in each row and column, to pad the extra blocks.

If we are unable to implement this algorithm or there is not enough time to implement for 4.3, it would be better to fail the import (with a user visible warning in the import dock IMHO) than to silently resize it, and perhaps have a dropdown where the user can manually choose to resize to 4 if they want.

The processing is now done without upscaling, but with a slight variation of the smearing algorithm from Godot's etcpak implementation.

CC @lyuma

I will admit I am not familiar with the w=1 and w=2 cases: I would think those also need to be padded to a multiple of 4, but maybe it is handled by basisu already so we would need to test and maybe fix separately if needed.

Thank you for the review! Images with small resolutions would trigger the "BasisUniversal cannot unpack level 1" error. As it turns out, this bug would also happen to all textures without mipmaps due to incorrect logic for checking the mipmap count, which I've fixed now.

Thanks!